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Cyclical Redundancy Check Using NuUifiers 

REFERENCE TO RELATED APPLICATION 

[0001] This application claims the benefit of U.S. Provisional Application No. 
60/456,818, filed March 21, 2003. 

TECHNICAL FIELD 

[0002] Embodiments of the invention relate to the field of data communications 
protocols, and to the error checking of data transported using these protocols. 

BACKGROUND 

[0003] Figure 1 A illustrates a conventional architecture of a line card, used in a 
network communication device that includes a link layer device and a framer. 
The link layer device typically includes components such as a network 
processor, a network co-processor, memory, data path switching element (DSE), 
network search engine (NSE), and a clock management block. The network 
processor and/or a framer usually performs packet processing functions. Packet 
processing functions may involve tasks such as packet pre-classification or 
classification, protocol conversion, quality of service assurance, service 
policing, provisioning, and subscriber management functions. The framer is 
used to transport data such as ATM (asynchronous-transfer-mode) cells, IP 
packets, and newer protocols, such as GFP (generic framing procedure) over 
SONET (synchronous optical network)/SDH (synchronous packet processing 
system hierarchy) links. On the port side, the framer may support optical- 
networking protocols for both SONET/SDH and direct data-over-fiber 
networks. The framer is coupled to the physical layer port such as a SONET 
device, which is coupled to a network medium such as optics. On the system 
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side, the framer interfaces to the Unk-layer device usually through standard 
buses, for example, the Universal Test and Operation Physical interface device 
for ATM (UTOPIA) or Packet Over SONET-physical layer (POS-PHY) buses. 
[0004] A packet processing function may also involve tasks such as error 
detection, and the cyclical redundancy check (CRC) algorithm is commonly 
used to implement this in communication systems. The CRC algorithm is 
among the strongest checksum algorithms available for detecting and correcting 
errors in communications packets, hi a high-speed design as the system 
operating speed increases it is common design practice to expand the internal 
bus width. An exemplary lOG (10 gigabits per second) system may have a 128- 
bit wide bus. 

[0005] A conventional architecture for implementing the CRC protocol is 
shown in Figure IB. This architecture comprises N number of CRC calculators 
to process an N-b>te wide bus. Figure IB shows an exemplary N byte wide 
input bus coupled to a plurality of byte-wide calculators comprising a first byte 
calculator, second byte calculator and so on up to an Nth byte calculator. The 
input data fi-om the input bus is passed to all the CRC byte calculators in 
parallel. The output of the CRC calculators is passed to a multiplexer, and the 
output of the multiplexer (a CRC output taken fi-om the selected CRC 
calculator) is chosen based on the byte-enable at the end of packet (EOP). 
[0006] A disadvantage of this conventional implementation is that the number 
of fast and pipelined CRC calculators required equals the number of bytes in the 
bus-width. Fast and pipelined CRC calculators typically require significant die 
area and consume a significant amount of power during their operation, hi this 
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conventional implementation, as the input bus-width increases the area and 
power required by the implementation increases rapidly. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

[0007] Embodiments of the invention may best be imderstood by referring to 
the following description and accompanjdng drawings that are used to illustrate 
embodiments of the invention in which: 

[0008] Figure 1 A illustrates a conventional architecture of a line card, used in a 
network communication device, that includes a link layer device and a framer 
[0009] Figure IB illustrates a conventional architecture for CRC calculation. 
[0010] Figure 2 illustrates one embodiment of a packet processing system 
having CRC computation circuitry with a nullification function. 
[0011] Figure 3 illustrates one embodiment of framer having a framer engine 
that includes CRC computation circuitry. 

[0012] Figure 4 illustrates one embodiment of CRC computation circuitry 
having CRC calculators and nuUifiers. 

[0013] Figure 5 illustrates an exemplary implementation embodiment of the 
CRC calculator and nuUifiers of the CRC computation circuitry of Figure 4. 
[0014] Figure 6A is a table illustrating XOR requirements of exemplary 
implementations using CRC computation circuitry of Figure 4. 
[0015] Figure 6B is a table illustrating the XOR requirements of a conventional 
architecture of CRC calculation versus an exemplary embodiment of CRC 
calculator and nuUifier functions of CRC computation circuitry of Figure 4. 
[0016] Figure 7 is a flow chart illustrates one embodiment of a method of cycle 
redundancy checking using a nullification function. 
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DETAILED DESCRIPTION 

[0017] In the following description, numerous specific details are set forth to 
provide a thorough understanding of the invention. However, it is understood 
that the invention may be practiced without these specific details. In other 
instances, well-known circuits, structures and techniques have not been shown 
in detail in order not to obscure the invention. A "line" as discussed herein that 
connects components may represent a single bit line, multiple bit lines, or buses. 
The phrase "coupled to" as used herein means connected directly to, or 
indirectly to through one or more intervening components. It should be noted 
that a "physical interface device" is also referred to as a "physical-layer device," 
[0018] An apparatus and method are described for a CKC computation 
operation using a nullification fiinction. hi one embodiment, the apparatus may 
include a cycle redundancy check (CRC) calculator, one or more CRC 
nulhfiers. In one embodiment, the CRC calculator may perform a closed loop 
function and the one or more CRC nullifiers may perform an operation outside 
of the closed loop fimction. 

[0019] The CRC computation operation has certain usefiil characteristics. A 
first characteristic is that as the bus width increases, the increase in the total 
logic required to perform the exclusive-or (XOR) operation of the CRC 
computation is mainly due to data terms. A second characteristic is that in a 
byte-enabled circuit, the byte validation operation is only required at the end of 
packet (EOP). 

[0020] Figure 2 illustrates one embodiment of a packet processing system 
having CRC computation circuitry with a nullification fimction. Packet 
processing system 200 may be used in a communication system such as a 
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computer, server, router, switch, server load balancer, add/drop multiplexer, 
digital cross connects, or other piece of communication equipment. In one 
embodiment, the packet processing system 200 may be implemented in a line 
card that links external network connections to each other. Some examples of 
line cards include a switch- fabric card, a time-division multiplexed data card, an 
Ethemet data card and an optical carrier (OC) data card. The commxmication 
system that hosts the line card may have, for example, a chassis and a backplane 
with many slots into which one or more line cards may be moimted. The line 
cards can be removed and inserted to change the number of ports or to support 
different communications protocols or physical interface devices. Altematively, 
packet processing system 200 may be implemented in other cards or integrated 
into other system components. 

[0021] Packet processing system 200 may be coupled to network medium 270 
by line 215, and to one or more mediums 280i-280m by line 211. Medium 
280i-280m may be similar or dissimilar mediums. In one embodiment, for 
example, medium 270 may be optics and medium 280i may be copper and 
medium 280m may be optics. Altematively, other similar and dissimilar 
configurations of mediums and network mediums may be used. In one 
embodiment, M may represent the number of communication ports that are 
coupled to the packet processing system 200. In one embodiment, packet 
processing system 200 may include physical interface device 290, link layer 
device 250, fi-amer 240 which includes CRC computation circuitry 360, and 
physical interface device 260. The link layer device 250 is coupled to the 
physical interface device 290 and fi'amer 240. In an alternative embodiment, 
fi"amer 240 may include multiple fi"amer engines and multiple CRC computation 
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circuitry. In an alternative embodiment, packet processing system 200 may 
include multiple physical interface devices 290. In one embodiment, the packet 
processing system 200 may be used as one communication channel from 
medium 280 to network medium 270. In an alternative embodiment, the packet 
processing system 200 may be implemented in multiple communication 
channels from multiple mediums to multiple network mediums. In one 
embodiment, the mediums and the network mediums may be copper. In 
alternative embodiments, similar and dissimilar mediums and network mediums 
may be used. 

[0022] Link layer device 250 may include a processing device 25 1, memory 
252, data path switching element (DSE) 253, network search engine (NSE) 254, 
and/or a clock management block 255. The components of the link layer device 
250 may be coupled to each other using one or more buses and/or lines as 
exemplified by bus 201. In one embodiment, for example, the components of 
link layer device 250 may be arranged and coupled in a look-aside 
configuration. In the look-aside configuration the processing device 251 of link 
layer device 250 may include a network processor and a network co-processor. 
In the look-aside configuration, the network co-processor resides beside the 
network processor outside the data path (bus 201), enabling packet co- 
processing in parallel with the network processor operation, increasing the 
overall throughput. In another embodiment, the components of link layer 
device 250 may be arranged and coupled in a streaming configuration. In the 
streaming configuration, the data path includes both the network processor and 
the network co-processor. Packets pass though the network co-processor, so it 
can act on packets as required and pass them directly to the network processor. 
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Alternatively, the components of link layer device 250 may be arranged and 
coupled in other configurations known in the art. 

[0023] In one embodiment, the processing device 25 1 may be a network 
processor. A network processor is a specialized microprocessor that supports 
the address sizes and common operations of networking equipment, and may 
perform some or all the packet processing functions. Typical network 
processors allow multiple processors to share the computational load of a high- 
speed data stream. The network processor may be used for processing 
information and/or controlling the movement of data packets to and from framer 
240. In another embodiment, the processing device 25 1 may be a field 
programmable gate array (FPGA). Alternatively, the processing device 25 1 of 
link layer device 250 may represent one or more other processing devices such 
as a general-purpose processor (e.g., a Motorola PowerPC™ processor or an 
Intel® Pentium® processor), a special purpose processor (e.g., a digital signal 
processor (DSP)), and a controller. In an altemative embodiment, the 
processing device 25 1 of the link layer device 250 may not be used, and the 
processing functions may be performed in the framer 240. 
[0024] The DSE 253 of link layer device 250 may be used to multiplex the data 
transmitted on bus 201. The NSE 254 of link layer device 250 may perform 
data route-table look-ups. In one embodiment, NSE 254 may be, for example, a 
content addressable memory (CAM) device. In an altemative embodiment, the 
operations of the NSE 254 may be performed by other devices, for example, a 
random access memory (RAM) with a hashing function performed in the 
processing device 251. The NSE 254 may also serve as a server-load balancer, 
which takes incoming traffic from the Intemet and distributes the processing 
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load among a number of servers. Memory 252 of link layer device 250 may 
included a random access memory (RAM), or other dynamic storage devices, 
for storing information (e.g., packets) and instructions to be executed by 
processing device 25 1 of link layer device 250. The memory 252 of link layer 
device 250 may be used for storing temporary variables or other intermediate 
information during execution of instructions by processing device 25 1 . The 
memory 252 of link layer device 250 may also include a read only memory 
(ROM) and/or other static storage device for storing static information and 
instmctions for processing device 25 1 of link layer device 250. It should be 
noted that link layer device 250 may also include other components that have 
not been illustrated. It should be noted that the components of link layer device 
250 have been shown with separate components. In an altemative embodiment, 
one or more of the components of link layer device 250 may be combined with 
other components into one or more integrated circuits. In one embodiment, the 
framer 240 may be coupled to the physical interface device 260. In an 
altemative embodiment, framer 240 may reside extemal to packet processing 
system 200. Framer 240 may include network protocol related circuitry to 
encode and decode the data that is transmitted on network medium 270 for error 
detection and correction purposes, a packet encapsulator that operates to map 
arbitrary data streams to a regular data stream, a framer engine, and a CRC 
computation circuitry 360 as discussed in detail below. 

[0025] Depending upon the particular design environment implementation, 
framer 240 may be coupled to a physical interface device 260. Physical 
interface device 260 may be, for example, a SONET device, an Ethernet card, a 
token ring card, or other types of physical interface devices for providing a 
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communication link to network medium 270 to and from the framer 240. 
SONET devices and Ethemet cards are known in the art; accordingly, a detailed 
discussion is not provided. In one embodiment, the physical interface device 
260 may be similar or dissimilar interfaces devices. In an alternative 
embodiment, framers 240 may reside external to packet processing system 200. 

[0026] It will be appreciated that the packet processing system 200 represents 
only one example of a packet processing system, which may have many 
different configurations and architectures. For example, some packet 
processing systems often have multiple buses, such as a peripheral bus, a 
dedicated cache bus, etc. As another example, packet processing system 200 
may be a line card. In one embodiment, the line card may be used in a system- 
to-network interface. Altematively, the line card may be implemented in an 
intermediate node in a network that provides a network-to-network interface, 
such as a wide area network (WAN). Such an intermediate node may provide 
an interface between similar networks or dissimilar networks. 
[0027] In one exemplary embodiment, packet processing system 200 may be a 
line card in a WAN connecting a data stream from Ethemet to SONET. In this 
embodiment, the line card is coupled to an optic network medium (network 
medium 270) and a copper medium (medium 280) by lines 215 and 211, 
respectively. The copper medium may include multiple serial ports. The 
copper medium is coupled to an Ethemet device (physical interface device 290) 
of the line card by line 211. The Ethemet device acts as a serializer/deserializer 
(SERDES) and may be a backbone link between multiple line cards. The 
Ethemet device is coupled to the link layer device 250 by line 212. In such an 
exemplary embodiment, the link layer device 250 may utilize a FPGA device as 



10 



016820.P279 



processing device 251. In this exemplary embodiment, packet processing 
functions, such as encapsulating the data into a communication protocol, such as 
ATM, GFP, and HDLC, that may be performed in processing device 251, are 
performed by the framer 240. The framer 240, acting as master device, receives 
isolated input data packets and frames the data to be output as back-to-back 
framed data to the SONET device (physical interface device 260 1) on line 214 
(described in detail below). The SONET device transmits the framed data over 
the optic medium (network medium 270) on line 215. In another embodiment, 
multiple packet processing systems may be implemented in multiple line cards, 
each line card including a framer and a SONET device coupled to a network 
medium, and the line cards may be coupled to each other through a backbone 
physical interface. In an altemative embodiment, the operations discussed 
below in the context of framer 240 may be performed in other devices, such as, 
for example, a network processor, co-processor, encapsulator, or switch. 
[0028] Figure 3 illustrates one embodiment of a framer 240 including CRC 
computation circuitry. Framer 240 formats data into a packet protocol 
structure that may be conducive to transmission and receipt on physical 
interface device 260. The packet protocol specifies the arrangement of data 
within the packet. The data may be transmitted along a transmission (Tx) data 
path from a link layer device 250 to a framer 240 on line 213, and from the 
framer 240 to a physical interface device 260 on line 214. Data may also be 
received along receive (Rx) data path from physical interface device 260 to 
framer 240 on line 324 and from framer 240 to link layer device 250 on line 
323. The data paths may be structural portions of the framer 240, which under 
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the influence of control through link layer interface 349, manipulates and passes 
data between link layer device 250 and physical interface device 260. 
[0029] In the transmission data path, framer 240 may include an input first-in- 
first-out (FIFO) 320, a packet encapsulator 330 and a framer engine 350i. 
Packet encapsulator 330 is coupled to an input FIFO 320 framer engine 350i by 
lines 311 and 312, respectively. Packet encapsulator 330 of framer 240 
performs data modifications to the packet and encapsulates the data into a 
commimication protocol. Framer engine 350i is coupled to the physical 
interface device 260 by line 214. Data arriving on line 214 faster than the 
throughput capacity of framer 240 may result in a dropped transmission. Input 
FIFO 320 operates to buffer the input data stream received from link layer 
device 250 in order to handle overloads of packets in the input data stream. The 
physical interface device 260 may output to a network mediimi 270. Network 
medium 270 may be copper or optics or other network mediums known in the 
art. In alternative embodiments, buffering may be accomplished by other 
means, for example, using a RAM or a FIFO coupled to framer 240 or memory 
252 of link layer device 250. 

[0030] Packet encapsulator operates to map arbitrary data streams to a regular 
data stream that are output to framer engine 350i on line 312. Framer engine 
350i operates to align the input data stream packets into frames to be 
transmitted to the physical interface device 260 on line 214. Framer engine 
350i frames the packets according to a framing specification. The framing 
specification may be a specification of the "protocol bits" that surround the 
"data bits" to allow the data to be "framed" into segments. The framing 
specification allows a receiver to synchronize at points along the output data 
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stream. Framer engine 350i includes CRC computation circuitry 360i to 
generate a packet error checking code. The packet error checking code may be, 
for example, appended at the end of a packet (or other locations in the packet) to 
provide error detection functionality to determine whether a received packet is 
good or whether errors are present in the data stream. Using packet error 
checking, CRC computation circuitry in a receiving packet processing system 
(e.g., similar to CRC computation circuitry 3602 in the Rx path) can detect 
transmission errors by recalculating a check code from the data packet and 
comparing it to a check value originally transmitted. It should be noted that the 
CRC computation circuitry 360i need not be located in the framer engine 350i 
and may be disposed at any place along the Tx data path. 
[0031] In the receive data path, framer 240 may include a packet decapsulator 
335 and a framer engine 3502- Packet decapsulator 335 is coupled to framer 
engine 3502 by line 322, Packet decapsulator 335 removes the framing data 
from packets. When framing data is removed from a packet, the data therein 
may become irregular. Framer engine 3502 operates to align data in the packets 
to achieve a continuous data stream. Framer engine 3502 is coupled to output 
FIFO 370 by line 321. Output FIFO 370 is coupled to physical interface device 
260 by line 323. Output FIFO 370 operates to buffer the data stream output to 
link layer device 250. It should be noted that framer engine 350 and/or framer 
240 may include other components known in the art that are not shown so as not 
to obscure an understanding of embodiments of the invention. For example, 
additional FIFOs may be present that operate to buffer the output data stream 
transmitted to/from physical interface device 260 on lines 214 and 324, 
respectively. It should be noted that the framer 240 has been shown with block 
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components only for ease of illustration and discussion. One or more of the 
block components of framer 240 may be combined with other components into 
one or more integrated circuits. 

[0032] Framer engine 3502 also CRC computation circuitry 36O2 for performing 
packet error checking. CRC computation circuitry 36O2 operates to verify the 
accuracy of the data stream by generating a code using the received data and 
comparing the generated code with a received code embedded in the data stream 
to determine whether a packet is good or errors are present. In one 
embodiment, the data stream checked at this receiving end by framer engine 
35O2 uses essentially similarly processes to those used to generate the code for 
transmission by framer engine 350i. As such, although illustrated separately, 
framer engines 350i and 3502 may be a single framer engine with CRC 
computation circuitry. The CRC computation circuitry 360 discussed below in 
relation to Figures 4 and 7 may be used to perform the operations of CRC 
computation circuitry 360i and 36O2 of Figure 3. 

[0033] Figure 4 illustrates one embodiment of CRC computation circuitry 
having CRC calculators and nuUifiers. In this embodiment, CRC computation 
circuitry 360 includes a single CRC calculator 410, a plurality of CRC nuUifiers 
420i to 420n-i and multiplexers (MUX) 430, 440 and 450. The inputs to the 
multiplexer 430 include a data byte (DataByte N) input signal 401 and a feed 
zero input signal 402. The output of multiplexer 430 is controlled by a byte 
enable (ByteEn_N) signal 407. The inputs to the multiplexer 403 include a 
default value input signal 403, and a CRC input signal 408 that is coupled to 
receive the output of the CRC calculator 410. The multiplexer 440 is controlled 
by the CRC reset or start of packet signal 405. The outputs of multiplexers 430 
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and 440 are coupled to the CRC calculator 410. In one embodiment, the output 
of the CRC calculator 410 is coupled to the output multiplexer 450 and to the 
CRC nullifiers 420i to 420n-i, where N is the width of the input data bus 490, in 
bytes. The outputs of the CRC nullifiers are coupled to output multiplexer 450. 
The output multiplexer 450 is controlled by a byte enable signal 406. The 
output from multiplexer 450 is the final CRC out value. The operation of the 
CRC computation circuitry 360 is discussed below in relation to Figure 7. 
Multiplexers, CRC calculators and nullifiers are known in the art; according a 
more detailed description is not provided. 

[0034] Figure 5 illustrates an exemplary embodiment of the operations of 1-bit 
CRC calculator and nuUifier using shifl: registers for an exemplary polynomial 
l+x'^2+x^l5+x'^16. In this exemplary embodiment, CRC calculator 410 
includes flip-flops C0-C15. The represents an XOR operation (e.g., XOR 
operation block 530). Data is input (Data input 505) to the linear feedback shift 
registers (LFSR) serially from the most significant bit (MSB) of the LFSR and 
the output of the flip-flops gives the computed value of the CRC calculator 410. 
[0035] The CRC calculator 510 operates on the assumption that the entire data 
field is valid if the current transfer to CRC calculator 510 does not contain an 
EOF character for the packet. However, when not all the data bytes are valid 
(possible only when current transfer contains the EOF), the CRC calculator 510 
is fed with zeros in place of invalid data bits. As the invalid data field is fed 
with zeros, the changes occurring in the new value of CRC are only a fiinction 
of the CRC terms. If the data input 505 is zero, then changes that occur in the 
CRC value will be only a function of the CRC terms, and not of the data terms. 
From this, the actual value of the CRC can be obtained by performing a reverse 
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XOR operation (as referred to as a 'back tracing' technique) on each of the CRC 
bits. As the byte validation operation is required only at the EOP, the CRC 
nuUifier operation can be performed in a separate clock cycle. The operation of 
the CRC nuUifier 520 is not a part of CRC calculator's closed loop function, so 
this operation can be performed in a following cycle or cycles without affecting 
the performance of the CRC calculator 510. When the CRC nuUifier' s 520 
operation takes place on the previous packet CRC value, the CRC calculator 
510 can compute the CRC value of the current transfer of current packet. 
[0036] The CRC nuUifier 520 is a 1-bit nuUifier for the same polynomial as the 
CRC calculator 510. As such, the nuUifier is derived based on the CRC 
polynomial. The changes that occur in the CRC value due to feeding of extra 
O's will not be a fiinction of the data input (which is 0) because the output of an 
XOR fimction does not depend on the inputs having logic value 0. The actual 
value of the CRC (which has been changed because of the feedings of O's) can 
be achieved by reverse XOR operations. As shown in figure 5, there is no data 
input for the CRC nuUifier 520 and the direction of shift operation is opposite to 
that in CRC calculator 510. The parallel CRC nuUifier for n-bits can be derived 
form the serial LFSR by looking ahead at the output of a flip-flop after n 
number of shifts. 

[0037] It should be noted that the length of the shift registers and the niunber of 
XOR operations depends on the selected polynomial. It should also be noted 
that the embodiment illustrated in Figure 5 is only exemplary and that any fast 
CRC calculator may be used for CRC calculator 410 of Figure 4. 
[0038] Figure 6A is a table illustrating a comparison of the niraiber of 2-input 
X-OR gates required to implement one CRC calculator and one CRC nuUifier 
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for different data-input bus-widths. This table uses the polynomial x^O + x^l + 
x^2 + x^4 + x^5 + x^7 + x^8 + x^lO + x^ll + x^l2 + x'^ie + x''22 + x^23 + 
x^26 + x^32. For a 128 bit bus width, for example, one CRC calculator may 
have 2,496 XOR gates while one CRC nuUifier may have 512 XOR gates. 
Because an CRC nuUifier requires a fewer number of XOR gates, CRC 
calculation that is implement with the multiple nuUifier architecture of Figure 4 
will require a lesser nimiber of XOR gates than CRC calculation implemented 
with the multiple CRC calculator architecture of Figure IB. 
[0039] Figure 6B is a table illustrating exemplary XOR requirements of a 
conventional architecture of CRC calculation utilizing multiple CRC calculators 
versus CRC computation using a single CRC calculator and multiple CRC 
nuUifiers. The architecture of Figure 4 utilizes one n-bj^e CRC calculator and 
n-1 byte to 1 byte CRC nuUifiers. So, for example, the total number of XOR 
operations required for 128 bit bus using the architecture of Figure 4 equals the 
XOR operations required by the 128 bit CRC calculator + the XOR operations 
required by a 120-bit nuUifier + the XOR operations required by a 104-bit 
nuUifier + the XOR operations required by a 96-bit nuUifier + the XOR 
operations required by a 88-bit nuUifier + the XOR operations required by a 80- 
bit nuUifier + the XOR operations required by a 72-bit nuUifier + the XOR 
operations required by a 64-bit nuUifier + the XOR operations required by a 56- 
bit nuUifier + the XOR operations required by a 48-bit nuUifier + the XOR 
operations required by a 40-bit nuUifier + the XOR operations required by a 32- 
bit nuUifier + the XOR operations required by a 24-bit nuUifier + the XOR 
operations required by a 16-bit nuUifier + the XOR operations required by an 8- 
bit nuUifier. 
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[0040] In contrast, the total number of XOR operations required for the same 
128 bit bus width using the architecture of Figure IB equals the XOR operations 
require by the 128 bit CRC calculator + the XOR operations require by the 120 
bit CRC calculator + the XOR operations require by the 1 12 bit CRC calculator 
+ the XOR operations require by the 104 bit CRC calculator + the XOR 
operations require by the 96 bit CRC calculator + the XOR operations require 
by the 88 bit CRC calculator + the XOR operations require by the 80 bit CRC 
calculator + the XOR operations require by the 72 bit CRC calculator + the 
XOR operations require by the 64 bit CRC calculator + the XOR operations 
require by the 56 bit CRC calculator + the XOR operations require by the 48 bit 
CRC calculator + the XOR operations require by the 40 bit CRC calculator + 
the XOR operations require by the 32 bit CRC calculator + the XOR operations 
require by the 24 bit CRC calculator + the XOR operations require by the 16 bit 
CRC calculator + the XOR operations require by the 8 bit CRC calculator. 
[0041] As can been seen in the table of Figure 6B, for a 128 bit bus, the 
architecture of Figure 4 requires 9,784 XOR gates versus the much greater 
22,819 number of XOR gates for the architecture of Figure IB. The improved 
architectiu*e significantly reduces the both the area and power required, and 
timing related challenges associated with CRC computation logic in high-speed 
data commimication systems 

[0042] Figure 7 is a flow chart illustrates one embodiment of a method of cycle 
redxmdancy checking using a nullification function. In this embodiment, 
starting from an Idle state 710, a check is performed to see if the next transfer is 
available, step 715. In step 720 a check is performed to determine of the byte 
valid value is equal to the bus width. If not, then multiplexer 430 (of Figure 4) 
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selects Feed Zero input 402 to feed zeros to CRC calculator 410 which appends 
zeros to the invalid data field, step 725. In parallel, in one embodiment, a check 
is performed to determine if a Start Of Packet (SOP) character is present, step 
730. 

[0043] A closed loop calculation function 702 may then be performed, and a 
nullification function 760 may be performed outside of the closed loop 
calculation function 702. In the closed loop calculation function 702, if a SOP 
character is present, signal 405 selects default value 403 to be output from 
multiplexer 440 and provided to CRC calculator 410. CRC calculator 410 
assigns the default value to the 'OLD CRC value, step 735. Otherwise, the 
computed CRC value is applied to the *OLD CRC value, step 740 and fed into 
the CRC calculation of the step 745. In this step 745, the CRC calculator 410 
computes the CRC over the full data bus width using a fast, pipelined CRC 
calculation function. CRC calculator functions are known in the art; 
accordingly a detailed description is not provided. 

[0044] In step 750, if the current transfer to the CRC calculator 410 does not 
contain the EOP, the calculated CRC value will be fed back as the OLD CRC 
value (on CRC input 408 of Figure 4) to the CRC calculator 410, step 740. If it 
does contain the EOP, the method proceeds to step 755. In this step 755, a 
check is performed to determine if the byte valid value is equal to the bus width. 
If so, then the output of the CRC calculator 410 is selected by output 
multiplexer 450, under the control of ByteEn 406, to obtain the final CRC out 
value 407 of Figure 4, step 770. If not, the calculated CRC value will go 
through a corresponding CRC nuUifier (one of CRC nuUifiers 420 1 to 420n-i) 
that performs a nullification function, step 760, to get the actual value of the 
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CRC (final CRC out value 407) depending on the byte valid information for 
step 770. 

[0045] An advantage of embodiments of the methods and apparatus discussed 
herein over the conventional architecture of Figure IB is that the conventional 
architecture requires N-CRC calculators to handle an N-byte wide bus, while 
embodiments of the methods and apparatus of the invention may utilize a single 
calculator to support an N-b34e wide bus. Such an improved architecture is 
advantageous because it requires significantly less area to implement and 
consumes less power than the conventional architecture of Figure IB. 
[0046] Although the methods and apparatus of the invention have been 
described at times in relation to hardware components, the methods and 
apparatus may also be implemented by software or a combination of hardware 
and software. Portions of the present invention may be provided as in the form 
of a machine-readable medium having stored thereon instructions, which may 
be used to program a computer system (or other electronic devices) to perform a 
process according to the present invention. A machine readable medium 
includes any mechanism for storing or transmitting information in a form (e.g., 
software, processing application) readable by a machine (e.g., a computer). The 
machine-readable medium may includes, but is not limited to, magnetic storage 
medium (e.g., floppy diskette); optical storage medium (e.g., CD-ROM); 
magneto-optical storage medium; read only memory (ROM); random access 
memory (RAM); erasable programmable memory (e.g., EPROM and 
EEPROM); flash memory; electrical, optical, acoustical or other form of 
propagated signal (e.g., carrier waves, infrared signals, digital signals, etc.); or 
other type of medium suitable for storing electronic instructions. 
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[0047] It should be appreciated that reference throughout this specification to 
"one embodiment" or "an embodiment" means that a particular feature, structure 
or characteristic described in connection with the embodiment is included in at 
least one embodiment of the present invention. Therefore, it is emphasized and 
should be appreciated that two or more references to "an embodiment" or "one 
embodiment" or "an altemative embodiment" in various portions of this 
specification are not necessarily all referring to the same embodiment. 
Furthermore, the particular features, stmctures or characteristics may be 
combined as suitable in one or more embodiments of the invention. In addition, 
while the invention has been described in terms of several embodiments, those 
skilled in the art will recognize that the invention is not limited to the 
embodiments described. The embodiments of the invention can be practiced 
with modification and alteration within the scope of the appended claims. The 
description is thus to be regarded as illustrative instead of limiting on the 
invention. 
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